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Method of announcing sessions 
Description 

The present invention relates to a method of announcing sessions particularly, 
although not exclusively to a method of announcing jnultimedia service sessions 
through a multicast network. 

Audio, video and other types of data may be transmitted through a variety of types 
of network according to many different protocolss. For example, data can be 
transmitted through a collection of networks usually referred to as the "Internet" 
using protocols of the Internet protocol suite, such as Internet Protocol (IP) and 
User Datagram Protocol (UDP). 

Data is often transmitted fhtough the Internet addressed to a single user. However, 
it can be addressed to a group of users. This is known as "multicasting". 

One way of multicasting data is to use an IP datacasting network.. Through such an 
IP-based broadcasting network, one or more sendee providers can supply different 
types of IP services including on-Une newspapers, radio, television and download of 
music songs, videos, pictures, games and software. These IP services are organised 
into sessions, each session comprising one or more media streams in the form of 
audio, video and/ or other types of data. 



To determine when and where these sessions occur, users refer to an electronic 
service guide (ESG). One example used in DVB is an electronic program guide 
(EPG). The. electronic service guide is usuaUy divided up into parts and transmitted 
to users. 

This approach, however, has several drawbacks. On the one hand, if any sessions 
arc updated, then the user usually has to wait until a new version of the service 
guide has been received before they receive notification of updated sessions. On 
the other hand, few sessions are usually updated. Therefore, much of the data 
received by the user is superfluous. This is wasteful both in terms of processing 
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• power and electxical power, both of which tend to be in short supply in .battery- 
powered mobile terminals. 

I 

( * 

The present invention seeks to provide an improved method of announcing sessions 
transmitted through a network. 

According to a first aspect of the present invention there is provided a method of 
announcing sessions transmitted through a network, the method comprising 
providing a first set of announcements describing a plurality of sessions and 
providing a second set of annoimcements describing at least one updated session. 

This has the advantage that it is possible to choose whether to be provided with the 
first set of announcements describing the pluraUty of sessions or to be provided 
with the second set of announcements describing any updated sessions; This allows 
updated sessions to be announced more quickly and efficiently. 

An updated session may be a new session which is added to the plurahty of 
sessions, a one of the plurality of sessions in which content is added, changed or 
deleted or a session which is deleted from the plurality of sessions. 

Providing the first set of announcements and providing die second set of 
announcements may comprise providing the first set of announcements through a 
first channel and providing the second set of announcements through a second, 
different channel. 

Providing the first set of announcements and providing the second set of 
announcements may comprise providing the first set of announcements through a 
first address, preferably a destination address, such as a first multicast IP address, 
and providing the second set of announcenients through a second, different 
address, preferably a destination address, for example a second, different multicast 
IP address, respectively. 
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Providing the first set of announce«.ents and providing the second set of 

announcements may comprise providing the fi,-^^ «L „ir 

, ■ ^ P "^'"^e %st set of announcements through a 

first port number and providing the second 

•. . ^ ^ set of announcements throueh a 

port numbex respectively, * 

Providing the first set of announcements and providing the second set of 
—cements may comprise providing the first set of announcements through a 
first logical channel and providing the second set of announcements through a 
second, different logical channel respectively. ' ' 

to 

P.cmdtog the to. of .nnou.c«„en« .nd p.<^ding .eeond se. „f 
™oca^ts .na, con.pdse including in each ,nnouncen.e„. of tot set of 
™ce„ents d... fo, identifying the announce„>,n. as an anno«ncen.en. which 
de,«he, a one of the p.u^., of ..ions and in each anno™.t of Uae second 
«. of annonncen-enta "'"'^^ _ccn.en. as an announcen.cn. 

whxch dccnbes a one of Ae a. leas, one updated session. 

P.o^dmg the to. set of announc=„.en.s «.d providing ie second set of 
announcen.en.s „ay conapdse including in each a.inoun.cen,en. of the to. se. of 
.nnouncen.en.s .especSve da. fo. speci^g a position 6f a co^sponding session 
w^. a to. portion of a session director, and including in each announcle . oT 
the second set ofannouncen.cn. respective da« for specifying a position of a 
correspondu^g session ^tinn a second portion of ti.e session direcory. 

^ Providing the to. se. of announcements and prodding the second sc. of 

™en,en. n., comprise providing ti.e to. se. of announcements ti.rough a 
. fi«t physr^ channel and prodding tire second se. of announcements through a 
second, different physical channel respectivel,. 

^ Providing the tot sc. of announcements and providing the second set of 

^cements may comprise providing the to. set of announcem^rts ti.rough a 
^ network and providing the second se. of am.o„ncemen« trough a second 
different network respectively. s^cona. 



The method may further comprise providing a third set of announcements 

describing another plurality of sessions iacluding the at least one updatfed session. 

t * 

The method may comprise providing the first set of announcements through a first 
channel, providing the second set of announcements describing at least one updated 
session through a second, different channel and providing a third set of 
announcements describing another plurality of sessions including the at least one 
updated session through the first channel. 

The method may comprise arranging the providing of said second set of 
announcements after the providing of said first set of announcements. 

The method may comprise arranging the providing of said first set of 
announcements and the providing of said third set of announcements at 
substantially during an overlapping or same time periods. 

Providing the first set of annoimcements and providing the second set of 
announcements may comprise transmitting the first set of announcements through 
the first channel and transmitting the second set of announcements through the 
second, different channel. 

The method may comprise transmitting the first set of announcements according to • 
a session announcement protocol (SAP), unidirectional hypertext transfer protocol 
(UHTTP), asynchronous layered coding (ALC) protocol or similar unidirectional 
protocol based on user datagram protocol (UDP). The method may comprise 
including a description of a corresponding session in each announcement, for 
example arranged according to session description protocol (SDP). 

The method may comprise providing means for determining whether all of the first 
set of announcements have been provided, for example by providing the first set of 
axmouncements as a series of linked messages. 



The method may comprise providing the first set of announcements in a first set of 
time slots and prdviding the second set of announcements in a second set of time 
slots, each' timeslot of the first set of timeslots being provided at a different time 
from each timeslot of the second set of timeslots! The method may comprise 
multiplexing the first and second sets of announcements. 

The method may further comprise providing a third set of annovmcements 
identifying the at least one updated session. Providing the second set o£ 
announcements describing the at least one updated session may comprise providing 
a set of announcements identifying the at least one updated session. Providing the 
second set of announcements describing the at least one updated sessipn may 
further comprise including a description of a corresponding session. Providing the 
second set of announcements describing the at least one updated session may 
comprise providing a set of notifications pointing to the at least one updated 
session. 

According to another aspect of the present invention tiiere is provided a method of 
announcing sessions transmitted through a network, the method comprising 
providing a first set of announcements describing a pluraUty of sessions and 
providing a second set of announcements identifying at least one updated session. 

The method may further comprise providing a third set of announcements 
describing the at.least one updated session. The method may comprise transmitting 
at least one of the sets of announcements according to asynchronous layered coding 
(ALC) protocol. The method may comprise transmitting at least one of die sets of 
announcements according to a protocol based on asynchronous layered coding 
(ALC) protocol. The method may comprise defining an asynchronous layered 
coding (ALC) protocol session and defining at least one ALC channel. The metiiod 
may comprise transmitting a set of metadata for describing die plurality of sessions 
via a first ALC channel. The metiiod may comprise transmitting a set of metadata 
for describing at least one updated session via a second, different ALC channel. The 
metiiod may comprise transmitting a set of metadata for identifying die at least one 
updated session via a tiiird, different ALC channel. The metiiod may comprise 



transmitting a set of metadata as a transport object. The method may further 
comprise defining a respective delivery table relating to the transport object and 
transimtting the delivery table. . ' ' 

According to a second aspect of the present invention there is provided a computer 
program which, when executed by data processing apparatus, causes the data 
processing apparatus to perform a method of announcing sessions trahstnitted 
through a network. 

According to a third aspect of the present invention there is provided a method of 
accessing sessions transmitted through a network, the method comprising 
selectively receiving a first set of announcements describing a pluraUty of sessions; 
and selectively receiving a second set of announcements describing at least one 
updated session. 

The method may further comprise determining whether all of said first set of 
announcements have been received. The method may further comprise selecting . 
not to receive further said first set of announcements and selecting to receive said 
second set of announcements. The method may fiarther comprise selecting not to 
receive a third set of announcements describing another pluraUty of sessions 
including said at least one updated session. The method may further comprise 
selecting to receive a fourth set of announcements describing at least one further 
updated session. 

The method may comprise using the second set of announcements to identify said 
at least one updated session. The method may comprise selecting to receive another 
set of announcements including a description of said at least one updated session. 
The method may comprise obtaining a description of said at least one updated 
session. 



According to another aspect of the present invention there is provided a method of 
accessing sessions transmitted through a network, the method comprising 
selectively receiving a first set of announcements describing a pluraHty of sessions 
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and selectively receiving a second set of announcements identifying at least one 
updated session. The method may further comprise selectively receiving a third set 
of announcements describing said at least one updated session. 

According to a fourth aspect of the present invention there is provided a method of 
accessing sessions transmitted through a network, the method comprising Ustening 
to a first set of announcements describing a pluraUty of sessions, determining 
whether said first set of announcements have been received; if said first set of 
announcements have been received, then stopping listening to said first set of 
announcements and listening to a second set of announcements describing at least 
one updated session. 



The method may further comprise stopping listening to a third set of 
announcements describing a further plur^ty of sessions including said at least one 
15 Updated session. 

According to a fifth aspect of the present invention, there is provided apparatus for 
announcing sessions transmitted through a network, the apparatus comprising 
means for providing a first set of announcements describing a plurality of sessions 
20 and means for providing a second set of announcements describing at least one 
updated session. 

According to a sixth aspect of the present invention there is provided apparatus for 
performing the method. 



According to a seventh aspect of the present invention there is provided apparatus 
for announcing sessions transmitted through a network, the apparatus comprising a 
first transmitter for providing a first set of announcements describing a pluraUty of 
sessions and a second transmitter for providing a second set of announcements 
50 describing at least one updated session. 



The apparatus may comprise means for managing an electronic service guide for 
announcing sessions to be transmitted through the network, means for managine 



content of sessions to be transmitted through the network, means for storing and 
electronic service guide for announcing sessions to be transmitted through the 
network, means for storing content of sessions to be transmitted through the 
network, means for determining changes to an electronic service guide, the changfes 
corresponding to updated sessions to be transmitted through the network, a server' 
for providing information relating to changes to an electronic service guide, the 
changes corresponding to updated sessions to be transmitted through the network, « 
server for providing content and/or means for transmitting data. 

According to an eighth aspect of die present invention there is provided apparatus 
for accessing sessions transmitted through a network, the apparatus comprising 
means for selectively receiving a first set of announcements describing a pluraUty of 
sessions and means for selectively receiving a second set of announcements 
describing at least one updated. session. 

The apparatus may comprise means for determining whether said first set of 
announcements has been received the apparatus being configured such that if the 
determining means determines that the first set of announcements has been 
received, then the means for selectively receiving said second set of announcements 
is configured to receive the second set of announcements. 

The apparatus may comprise means for selectively receiving a third set of 
announcements describing another plurality of session including the at least one 
updated session, die apparatus being configured such that if said determining means 
determines that the first set of announcements has been received, then the means 
for selectively receiving the third set of announceinents is configured not to receive 
or not to forward the third set of announcements. 

The apparatus may comprise means for receiving data, means for filtering an 
electronic service guide for announcing sessions to be transmitted through the 
network, means for storing an electronic service guide for announcing sessions to 
be transmitted through the network, means for browsing an electronic service guide 



for announcing sessions to be transmitted throjigh the network, means for filtering' • 
content, means for storing content and/or m«s^s for browsing content. 

The apparatus may be a handheld mobile communications de-rice. 

According to a ninth aspect of the present invention there is provided a system for 
presenting program schedule data on a display, said system comprising at least two 
announcements, the schedule data being organized at least partly from a first set of 
announcements describing at least partly a pluraUty of sessions and at least partly 
from a second set of announcements describing at least one at least partly updated 
session. 

According to an tenth aspect of the present invention there is provided a system for 
presenting program schedule data on a display, said system comprising at least two 
announcements, the schedule data being organized at least pardy from d first set of 
repeatable announcements describing a plurality of sessions, at least pardy from a 
second set of repeatable announcements describing at least one at least pardy 
updated session and at least session descriptions of at least one of the repeatable 
announcements for defining whether the at least one of the first and second 
announcements is received or not. 

According to a eleventh aspect of the present invention there is provided a system 
for delivering program schedule data to end-user terminals, said system comprising 
two sets of announcements, each set comprising at least one announcement, the 
schedule data being organized at least partly from a first set of announcements 
describing at least pardy a pluraUty of sessions and at least pardy from a second set 
of announcements describing at least one at least pardy updated session. 

According to a twelfdi aspect of the present invention there is provided a system 
for presenting program schedule data to end-user terminals, said system comprising 
at least two set of announcements, each set comprising at least one announcement, 
the schedule data being organized at least pardy froin a first set of repeatable 
announcements describing a plurality of sessions, at least partly from a second set 



of repeatable announcements describing at least one at least partly updated session 
and at least session descriptions of at least one of the repeatable announcements for 
defining whether the at least one of the first and second announcement^ is received 
or not. .1 

The second set of announcements may include a version number of each updated 
session for allowing a client to detect if they have missed. an earlier update. If a 
client detects it has missed an earlier update and is not currently receiving the first 
set of announcements, the client may start receiving the first set of announcements 
until it has received a full and latest version of the program schedule data. If the 
client detects that it has received a fiiU and latest version of the program schedule 
data, it may. stop receiving the first set of announcements and continues receiving 
only the second set of announcements. If the client detects it has missed an earlier 
update, it may fetch a full and latest version of the program schedule data over an 
interactive network. Each set of repeatable announcements may be divided into 
segments before transinission and a location of each segment within a whole 
transfer may be indicated in a framing field of each respective segment; the 
indicated location may enable clients to determine whether they have received all 
segments that constitute a given set or whether they need to wait for receiving more 
. segments. 

The program schedule data may be viewed either directly by a human end-user or 
automatically used by a software application. The program schedule data may be 
presented progressively to a human end-user or made progressively available to an 
automatic software application as the said data is being received. The program 
schedule data may be viewed by a human end-user via a graphical user interface. 
The program schedule data may be used by a personal video recorder. 

Embodiments of the present invention will now be described by way of example 
with reference to the accompanjring drawings in which: 
Figure 1 is a schematic diagram of a multicasting system 1; 
Figure 2 shows content stored in a content database; 
Figure 3 shows a session directory; 



Figure 4 shows electtonic service guide data stored in an electronic service guide 
database;- ' '. . • ' 

Figure S" Shows updated content stored in a content database; 
Figure 6. shows an updated session directory; 

Figure 7 shows updated electronic service guide data stored in an in an electronic 
services guide database; 

Figure 8 shows a first embodiment of a session directory before an update 
according to the present invention; 

Figure 9 shows the session directory shown in Figvire 8 after the update in 
accordance with the present invention; 

Figure 10 shows electronic service guide data before an update in accordance with 
the present invention; 

Figure 1 1 shows electronic service guide data after an update in accordance with the 
present invention; 

Figure 12 shows a session announcement message using SAP and SDP protocols in 
accordance with the present invention; 

Figure 13 illustrates transmission of a description of asession directory using session 
announcement messages shown in Figvire 12 in accordance with the present 
invention; 

Figure 14 is a process flow of a method of operating a datacast service system in 
accordance with the present invention; 

Figure 1 5 is a process flow of a method of operating a datacast cUent in accordance 
with the present invention; 

Figure 16 shows a second embodiment of asession directory after an update in 
accordance with the present invention; 

Figure 1 7 shows spUtting electronic service guide data into data segments in 
accordance with the present invention; 

Figure 18 shows another session announcement message using UDP and UHTTP 
protocols in accordance with the present invention; 

Figure 19 illustrates transmission of a description of asession directory using session 
announcement messages shown in Figure 18 in accordance with the present 
invention; 
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Figure 20 shows notification of update data in accordance with the present • ' 
invention; " ' 

Figure 21 shows another session announcement message using UDP arid ALC 
protocols in accordance with the present invention; , . t 

Figure 22 illustrates transmission of electronic service guide data using ALC 
channels in accordance with the present invention; ' 
Figure 23 shows transmission of a description of a session directory using session 
annoiincement messages using time division multiplexing in accordance -with the 
present invention; 

Figure 24 shows a schematic diagram of a terminal used to receive multicast data in 
accordance with the present invention and 

Figure 25 shows an electronic service guide browser in accordance with the present 
invention. 

15 Multicasting system 1 

Referring to Figure 1 , a multicasting system 1 is shown. In this example, the 
multicasting system 1 is an internet protocol' (IP) datacast system. The multicasting 
system 1 may include a datacast service system 2, a datacaster 3, a datacast network 
4 and a plutaUty of clients 5. For clarity, only one cUent 5 is shown. 
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An administrator 6 provides scheduled content, such as audio, video and/or other 
types of data, for datacasting to dients 5 and provides metadata for describing the 
content. The metadata includes information regarding transmission of content. 

The datacast service system 2 generates IP streams carrying content items and 
related metadata for datacasting to cUents 5. The datacaster 3 receives IP streams 
from the datacast service system 2, provides Layer 2 encapsulation and modulation 
and transmits the IP data to clients 5 over the datacast network 4. The datacast 
network 4 is a point-to-multipoint network for delivering IP-based data. Typically, 
tiie datacast network 4 supports a pluraUty of simultaneous datacasts to chents 5. In 
tiiis example, the datacast network 4 does not provide a return data patii from the 
dient 5 to tile datacaster 3. The datacast network 5 may be for example a Digital 
Video Broadcasting (DVB) network, a Digital Audio Broadcasting pAB) network. 
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an Advanced Television Systems Committee (ATSC) network, an Integrated 
Services . digital Broadcasting (ISDB) network or ^ Wireless Local Area Network 
(WLAN)-. The client 5 comprises a terming for receiving content and content 
descriptions over the datacast network 4 and presenting them to an end-user 7. The 
terminal may be fixed, such as a desk-top personal computer or a television set:top 
box. or portable, for instance a lap-top or notebook personal computer, personal 
digital assistant or mobile telephone handset which have receiving means for 
receiving broadcast trasnsmissions. 

The datacast service system 2 includes an electronic service guide (ESG) 
management module 8. an ESG database 9 for storing metadata for the electronic 
service gmde. a service discovery server 10. a content management module 11 a 
contents database 12 for storing content for datacastingand a content server iV. . 

Electronic Service Guide (ESG) is a set of metadata describing available content 
such as e.g. streaming media and downloadable files with indication of their 
transmission schedules. The foU or partial metadata of a single ESG is delivered to 
receiving chents in an ESG session that may comprise one or more chamiels. 

TTae ESG management module 8 allows the administrator 6 to control metadata for 
describing datacast content. Content items can be grouped into IP services and IP 
sessions. Content items can be allocated (or de-aUocated) time slots for 
transmission. Thus, the metadata describes the structure of content items as a 
hierarchy of IP services and IP sessions. The metadata may also include 
information on the transmission schedule of IP sessions and individual content 
Items within IP sessions. 



30 



The content management module 11 aUows the administrator 6 to add. replace and 
delete content items in the content database 12. 

The service discovery server 10 generates announcements of IP services and IP 
sessions based on the metadata found in the ESG database 9. The announcements 
are sent to the datacaster 3 for transmission over the datacast network 4 The 



announcements may be transmitted repetitively by repeating.them in carousel style . 
or by transmitting them multiple times. 

As will be explained in more detail later, two kinds of announcements are generated. 
A first kind of announcement describes a full IP service directory and a second kind 
of announcement describes updates to the IP service directory. 

In one embodiment of the present invention, the second kind of announcements is 
used to transmit an updated session directory. 

In anothex embodiment of the pxesent invention, the second kind of 
announcements compxises identification of those parts of the service directory that 
have been changed. The second kind of announcements triay comprise only such 
identification. Such second kind of announcements may be regarded as a 
notification of updates. The second kind of announcement comprisiiig only 
notification of updates can be sent more firequently than the secpnd kind of 
announcements comprising updates. The second kind of announcements may 
comprise both one or more notifications of updates and one or more updates, 
whereby the updates are selected from the set of updates available at the time of the 
announcement. 



The content server 13 retrieves scheduling information from the ESG database 9 
and, based on the scheduling information, retrieves content from the content 
database 12 and sends it to the datacaster 3 for transmission over the datacast 
network 4. 



The cUent 5 includes a datacast receiver 14, a service discovery cUent 15, an ESG 
database 16 for storing metadata for the electronic service guide, an ESG browser 
17, a content filtering appUcation 18, a content database 19 and a content browser 
20. 



The datacast receiver 14 receives data over the datacast network 4 whereupon it 
demodulates and decapsulates the data. In this case, the datacast recover 14 



15 



forwards the demodulated and decapsulated d^ta to an IP stack (not shown). The 
demodxilated and decapsulated data comprises. IP packets carrying cpntent streams 
or metadata describing content. The IP packets are forwarded from the stack (not 
shown) to IP-based applications 15, 18 running on the client 5. 

The service discovery client 15 receives the IP packets on one or more given 

addresses and one or more given ports for carrying IP service announcements. As 

will be explained in more detail later, the service discovery client 15 can. receive 

announcements of the first type describing the fuU service directory and, either 

alternatively or additionally, announcements of the second type describing updates 

to service directory. The IP packets carry metadata which can be stored in the ESG 

database 16 or forwarded directly to the ESG browser 17. 

■ 

The ESG database 16 has an information structure very similar to the server-side 
ESG database 9. The ESG database 16 is initially empty, for example when the 
client 5 is first switched on, but fills up and is updated as IP session announcements 
are received from tibe datacast service system 2. 

The ESG browser 17 allows the end-user 7 to view schedules and descriptions of IP 
services, sessions and content items available £tom the datacaster service system 2. 
The ESG browser 17 can retrieve metadata from the ESG database 16 or receive 
metadata directly from the service discovery client 15. 

The content filtering application 18 receives the IP packets on one or more given 
addresses and one or more given potts configured by the content browser 20 or 
other appUcatipns ruiming on the chent. The IP packets carry content which can be 
stored in the content database 19 or forwarded directly to the content browser 20. 

The content browser 20 is loaded and run when the end-user 7 has selected a 
particular datacast content item for consumption. The content item can be received 
in real time or retrieved from the content database 19. The content browser 20 can 
be for example a Web browser, an MPS player or a streaming video client. 



-16- 



10 



The multicasting system 1 may allow automatic content uploading by extemal 
content ptovidexs (not shown) and forwarding of Internet-based content. The 
datacaster 3 can also deliver content to a plurality of datacast network^' (not shown), 
each datacast network composing one or more transponders. , • 

In- an embodiment of the present inveiation, one or more ESG proxies (not shown) 
may be provided between the datacaster 3 and the client 4. Each ESG proxy is 
capable of receiving and transmitting ESG metadata or parts of ESG metadata, 
updates and/or notifications of updates. Each ESG proxy can filter ESG metadata 
or parts thereof, including updates and notifications of updates firom one or more 
ESG senders and output the filtered ESG metadata to one or more ESG sessions. 
Logically, an ESG proxy fits in between ESG senders and receivers. A proxy may 
also cache ESG metadata or parts diereof including updates and notifications of . 
updates and may provide its own bandwidth control or congestion conteol schemes 
15 on the output. 

Sessions 

Referring to Figure 2, content 21 is shown which is stored in the content database 
12 and which includes first, second, third and fourth sessions 22„ 222, 223, 23^. The 
first, second and third sessions 22,. 22^, 22, comprise data relating to soccer. For 
example, the first session 22, may include text relating a game, the second session 
.222 include video streaming and the third session may include audio streaming 223 
The fourth session 22^ comprises data relating to hockey. A session 22^, 222, 
23^ may comprise a single IP stream or a plurality of IP streams. 
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Session Directory 

Referring to Figure 3, a session directory 23 is shown according to which the 
sessions 22„ 222, 223, 224 are organised. The session directory 23 includes, at a first 
level, categories such as sports 24,. Further examples of categories include arts, 
business, computers, games, news and shopping and other categories which are 
commonly found on web portal sites. Each category includes, at a second level, 
sub-categories, such as soccer 25, and hockey 252, Each sub-category may be 
further sub-divided. For instance, the soccer sub-category 25, can be divided into 
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soccer leagues, each of which may be divided into league divisions and each of 
which m turn may be divided into players. ^ ' 

Each category, sub-category or further sub-category may include one or more 
5 sessxons. For example, the soccer sub-category'25, includes the first, second and 
durd sessions 22„ 22^, 223, while the hockey sub-category category 25, includes the 
foxxtth session 224. 

Referring to Figure 4. ESG data 26 is shown which is stored in the ESG database 9 
10 . The electronic service guide data 26 includes first, second, third and fourth sets of 
metadata 27., 27„ 27,, 27, for describing the first, s.cond, third and fourth sessions 
22., 22, 223, 22, respectively. The ESG data 26 reflects the structure of the session 
ditectoty 22. 

1^ The ESG data 26 is transmitted to client. 5 so as to provide an ESG for users 

However, there is a problem if the ESG data 26 needs to be updated, as will now be 
explained:. 

. Referring to Figures 1. 2, 3 and 4. initially, ESG data 26 is transmitted from the 
20 datacast service system 2 to the client 5. The datacast service system 2 sends sets of 
metadata 27„ 27„ 27,, 27, to the datacaster 3 to be transmitted to cUents 5 The ■ 
chent 5 begins to receive the sets of metadata 27„ 27„ 273. 27, and starts to fiU the 
initially empty ESG database 16. EventuaUy, aU d.e sets of metadata 27„ 27, 27 
27, are received and are stored in the ESG database 16. At this point, the ESG il' 
25 complete. 

Referring to Figure 5. the content database 12 is updated and corresponding 
updated content 21' is shown. The updated content 21 ' includes an updated session 
22/ and a new session 223. For example, the first session 22. may be updated by 
^ replacing a match preview with a match report. The new session 22, may be a text 
file with a hockey fixture list. 



Referring to Figure 6, an updated session directory 23* is shown and includes' the 
updated session 22/ and the new session 225. 

I 

Referring to Figure 7, an updated ESG data 26' is shown including an updated fi±st 
.sets of metadata 27*,, and a new set of metadata 27s. 

Referring to Figures 1, 4, 6 and 7, the updated ESG data 26' is transmitted from the 
datacast service system 2 to the client 5. The datacast service system 2 sends the 
updated ESG data 26' to the datacaster 3 for transmission. The client 5 then 
receives updated sets of 'metadata 27,'. 27^, 273, 27^. 27s. However, the. client 5 does 
not know whether each set of metadata 27,', 21^,21^, 21 21^ relates to existing or 
updated sessions. Thus, each incoming set of metadata 27,', 272, 273, 274, 275 is 
compared with stored sets of metadata 27„ 272, 273, 274 check whether they . 
relate to an updated data session. Processing metadata in this way is wasteful. 
Furthermore, there can be delay between the first session 22, being updated and the 
electronic service guide at the client 5 being revised. 

Therefore, it is desirable to provide an improved session directory and an improved 
ESG. 

One solution to the problem is to spht the session directory and divide transmission 
of the ESG accordingly. Description of the session directory is transmitted by 
sending two types of session announcements one for describing the full session 
directory and another for describing an updated session directory, as will now be 
described in more detail: 

Split S ession Directory — First 'Example 

Referring to Figures 8 and 9, a first embodiment of asession directory 28, 28' 
according to the present invention is shown before and after an update respectively. 

The session directory 28, 28' is split into two parts at a relatively high level, in this 
example above the category level, and the two parts are referred to as the full 
session directory 29, and the updated session directory 29^ respectively. Later, 
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second example, a session directory is described which is split at a relatively low 
level. 



The foU session directory 29, includes substantially the same categories described 
earlier, such- as sports 24,. Each category inducies sub-categories, such as soccer 25, 
and hockey 252- Similarly, there may be further sub-categories. Each category, sub- 
category or any further sub-category may include one or mote sessions. In this 
case, the soccer sub-category 25, includes the first, second and third sessions 22„ 
222, 223 and the hockey subrcategory category 252 includes the fourth sessions 224. 

The updated session directory 292 also includes categories which correspond to the 
categories in the full session directory, such as sports 30,. Similarly, each 
corresponding category includes corresponding sub-categories, such as soccer 31, 
and hockey 3I2. Similarly, there may be corresponding further sub-categories. Each 
corresponding category, corresponding sub-category or any corresponding fiitther 
sub-category may include, if there has been an update, one or more updated 
sessions. 

Before the update, the updated session directory 292 does not list any sessions. 

After the update, the updated directory 29^ Usts updated sessions. In this case, the 
soccer sub-category 31, includes the updated, first session 22,' and the hockey sub- 
category category 3I2 includes the fifth session 22s. 

This configuration is used to send two types of session announcements. One type 
of announcement is used to describe aU sessions. Another type of announcement is 
used to describe updated sessions. 

Thus, the client may listen initiaUy to announcements of the fist type so as to 
receive a description of aU the sessions, i.e. the full session directory. Once the 
cUent has received the description of aU sessions, the client may Hsten only to 
announcements of the second type so as to learn of any updates to the sessions. 



Session Jinnommments using SAP and SDP . i . ' 

Refetring to Figures 10 and 11, a first example of ESG data 32, 32' in accordance 
with the present invention is shown before and after the update. • ' 

t * 

t , 

The ESG data 32 includes first, second, third and fourth sets of metadata 33„ SSj, 
333, 334 for describing the first, second, third and fourth sessions 22„ 22^^ 22^, 22^ 
respectively. ' « . ' 

The updated ESG 32' includes the updated first, second, third, fourth and fifth sets 
of metadata 33,', 332, SSj, 33^, 33s for describing the updated first, second, third, 
fourth and fifth sessions 22/, 22^, 323, 224, 22s respectively. 

A Session Announcement Protocol (SAP) is used to transmit sets of metadata 33„ 
33/, 332, 333, 334, 33s to clients 5 and a Session Description Protocol (SDP) is used 
to describe the sessions 22„ 22,', 22^, 22,, 224, 22s. Reference is made to "Session 
Announcement Protocol" by.M. P. Maher, C. Perkins & E. Whelan, RFC 2974, 
IETF, October 2000 and to "Session Description Protocol" by M. Handley & V. 
Jacobson, RFC 2327, IETF, April 1998. 

The use of the Session Announcement Protocol and the Session Description 
Protocol advantageously permits information describing the structure of session 
directories to be transmitted to cHents 5. Reference is made to "Describing session 
directories in SDP" by R. Finlayson, Internet Draft, IETF, January 2001 and 
"Towards multicast session directory services" by A. Santos, J. Macedo & V. Fteitas. 

Referring to Figure 12, a session announcement 34 is shown. The session 
announcement 34 comprises an SAP header 35 and payload in the form of an SDP 
description 36 of a session. The SDP description 36 includes a set of metadata 33 
for describing a session. 

Referring to Figure 13, a description of the session directory 28 is transmitted by 
sending two types of session announcements 37„ 37^ each describing a session 
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directory, in this case the £uU session directory 29, and the updated session directory 
292 respectively. 

The first lype of session announcements 37, is used to send descriptions of all 
sessions, Le. the full session directory 29,. During an earlier cycle 38„ the 
announcements 34„ 342, 343, describe all sessions 22„ 222, 223, 22^ before the 
update and, during a later cycle 383, the announcements 34,', 342, 3^3, 34^, 345 
describe all sessions 22,', 222, 223, 22^, 22s after the update. 

The second type of announcements 372 is used only to send descriptions of sessions 
that have been added, removed or changed since thp transmission of 
announcements 34„ 342, 343, 34^ during the earUer cycle 38,. In this example, no 
cycle precedes the earlier cycle 38,. Thus, during the eariier cycle 38„ there are no 
announcements of the second type 372. During the later cycle SSj, the 
announcements 34,', 345 describe updated sessions 22,', 22s (Figure 9). 

UsuaUy, there -will be more than two cycles 38„ 382 of announcements. 
Furthermore, more sessions may be updated. Thus, each subsequent cycle (not 
shown) may or may not include announcements of the second type 372- Optionally, 
announcements of the second type 372 may be sent repeatedly during a cycle to 
protect against irrecoverable transmission errors. 

Preferably, the structure of the session directory 28 (Figure 9) is described using a 
hierarchy of multicast IP addresses using SDP and SAP. 

A process of describing the sttucture of the session directory 28 includes 
transmitting a first session announcement on a given mxilticast address. The first 
session announcement includes a second multicast address and other details relating 
to a session directory. The process includes transmitting a second session 
announcement on die second multicast address. The second session announcement 
includes a third multicast address and otiier details relating to a session sub- 
directory. Because sub-directories in turn can be used to announce a succeeding 
level of a session directory, the session directory hierarchy can be organized as a 



tree of any depth. In this example, a root or default session announcement (not 
shown) is transmitted on a widely known address, which specifies a pair of 
addresses for receiving announcements of the first and second types 37^, 31 2, 
respectively. ^ , 

One or more "category" fields may be included in the session announcements for 
allowing clients 5 to filter and organize session announcements. 

As described earlier, announcements of the first type 31^ are transmitted on a first 
IP address, such as 224,2.17.0. . • * 

Referring to Figure 13, the first session announcement 34, may include an SDP 
description 36 of the first session 22, including, for example: 

osjsmlth 2890842807 2890844525 IN 1P4 10.47.16*5 
C=IN IP4 224.2.17.12/127 
ta2892D54126 2892399688 
madata 9875 UHTTP TOP 
ascat s Full • Sports • Soccer 

If the first session announcement 34^ is updated, then the updated first session 
announcement 34,' may include an SDP description 36 of the updated first session 
22/ including, for example: 

v=0 

0=jsxaith 2890842807 2890844526 IN IP4 10.47.16.5 
caIN 1P4 224.2.17*12/127 
ta2892054126 2892399726 
msdata 9875 UHTTP TOP 
ascat t Full • Sports • Soccer 



Likewise, the second session announcement 34^ may include an SDP description 36 
of the second session 222 including, for example: 
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v=0" 

o=jsmith 2890842807 2890844526 IN IP.4 ib.47^16.5 
csIN IP4'224.2.17.13/127 
t=2892054126 2892399726 

mavideo 9875 RTP/AVP 31 / 
ascat : Full , Sports • Soccer 

Announcements of the second type 31^ are transmitted on a second IP address,' 
such as 224.2.17.1. \ 

Referring stiU to Figure 13, the updated first session announcement 34i* may include 
an SDP description 36 of the updated first session 22/ (Figiire 9) including for 
example: 

v=0 

osjsmith 2890842807 2890844526 IN IP4 10.47.16.5 
C=1H IP4 224.2.17.12/127 
ts2892054126 2892399726 
madafca 9875 TOTTP UDP 
ascab s Update • Sports . Soccer 

The updated session 22/ (Figure 9) may be identified as an updated session in a 
number, of ways: 

Firstly, the first session announcement 34, and the updated first, session 
annoiincement 34,' specify different version numbers in the "o-" field, namely 
2890844525 and 2890844526 respectively. Thus, identifying an updated session 
may include comparing version numbers of the first and updated first session 
announcements 34„ 34,' and noting different version numbers. 

Secondly, the updated first session announcement 34,' is provided through a 
different channel, in this case a different IP address, which is reserved for 
announcements relating to updated sessions. Thus, identifying an updated session 
may include receiving an announcement on a different channel. 
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Thirdly, the updated first session announcement 34/ includes a category field, 

I 

which identifies the fact that the session announcement relates to an update. Thus, 
identifying an updated session may include determining whether an announcement 
identifies itself as relating to an update and/or determining a position within a . • 
5 session directory. 

Method of operating the datacast service system 2 

Referring to Figures 1 and 14, a method of operating the datacast service system 2 is 
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shown. 



The ESG management module 8 identifies whether sessions have been updated in 
the content database 12 (step SI). If it identifies any updated sessions, then it 
updates correspoixding sets of metadata in the ESG database (step 82). Updating 
may include adding or deleting metadata. Metadata is passed to the service 

IS discovery server 10, which generates updated session announcements for any 

updated sets of metadata (step S3). The service discovery server 10 forwards a first 
set of announcements describing a plurality of sessions, in other words full session 
announcements, and a second set of announcements describing at least one updated 
session, in other words updated session announcements, to the datacaster 3 through 

20 different channels, such as different IP addresses (steps S4 & 85). The datacaster 3 
receives the announcements and transmits them over the datacast network 4 to each 
clients 5. 

Method of operating client 5 
25 Referring to Figures 1 and 15, a method of operating the chent 5 is shown. 

The cUent 5 checks whether it has received all the session announcements of the 
first type 37, (step Tl), If not, the cUent 5 Kstens to both types of announcements 
37„ 372 (step T1& T2). However, if the cUent 5 has received all the session 
announcements of the first type 37„ then it can stop hstening to announcements of 
the first type 37, and continue Ustening only to announcements of the second type 
372- This has the advantage that it saves processing power and electrical power 
because fewer session announcements are received and/or processed. 
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The first and second types of announcements^ 37,, S?^ may include multicast 
addresses of announcements relating to other sessibn directories, which in turn may 
include multicast addresses of announcements relating to further session directories. 

Announcements of the first type 37, may be considered as relating to a session 
directory including sub-directories to a given depth of directory hierarchy. 
Announcements of the second type 37^ may lil^ewise be considered as relating to a 
session directory including sub-directories to a given depth of directory hierarchy. 
If announcements of either type 37„ 37^ relate to more than one session directory, 
then they can be used to announce the details of a different sub-tree of the IP 
session hierarchy. Thus, if descriptions of multiple subdirectories are transmitted 
using announcements of the first type 37„ then the client 5 may stop receiving 
announcements relating to a particular subdirectory as soon as it has received all the 
different session descriptions of that subdirectory. 

Split S essiott Directory - Second Example 

Referring to Figure 16, a second embodiment of asession directory 28" according to 
the present invention is shown. The session directory 28" is split into two parts at a 
relatively low level, in this example above die session level, and the two parts are 
referred to as die full session directory 29,„ 29,, and die updated session directory 
292,, 292b respectively. 

The ESG data 32 and die updated ESG data 32' are modified to reflect the structure 
of die second embodiment of a sessibn directory 28" according to die present 
invention. 

Session Announcements using UHTTP 

A drawback of using session announcements employing SAP and SDP is that it is 
difficult for a chent 5 to estabUsh when it has received enough announcements of 
die first type 37, to describe die fiiU session directory 29,. Announcements 34,», 
342, 343, 34^, 34s may be lost or corrupted and diese protocols do not allow such 
events to be detected. 
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In an alternative embodiment, this problem is solved by Unking together session 
announcements describing the iiill session directory 29,. ■ ' 

I 

I 

5 A Unidirectional Hypertext Transfer Protocol (UHTTP) is used to implement a 
concatenated transfer of multiple session descriptions and references are made to 
the Society of Motion Picture and Television Engineers standard SMPTE 364M- 
2001 "Declarative Data Essence — Unidirectional Hypertext Transport Protocol" 
and to "Appendix C: The Unidirectional Hypertext Transfer Protocol (UHTTP)" in 
W Enhanced Content Specification, Advanced Television Enhancement Forum. 

UHTTP supports MIME mvdtipart/related content-type protocol, so allowing a 
single UHTTP transfer to comprise multiple independent MIME objects and 
reference is made to "The MIME Multipart/Related Content-type" by E. Levinson. 
IS RFC 2387, IETF (1998), 

Referring to Figure 17, tiie ESG data 32 is considered as a single resource 39 which 
can be spUt into a plurahty of data segments 40„ 40„ 40,. In this example, there are 
fewer datk segments than there are sets of metadata. However, the number of data 
20 segments may be equal or greater tiian the number of sets of metadata. Redundant 
error correction segments (not shown) may be calculated and interleaved xntJa tiie 
data segments 40„ 40^, 4O3. The updated electronic service guide data 32' is 
processed in the same way." 

2S Referring to Figure 1 8, a user datagram protocol (UDP) packet 41 is shown which 
includes a UDP header 42 and a UDP payload 43. The UDP payload 43 inchades a 
. UHTTP packet 44 which includes a UHTTP header 45 and a data segment 40„ 40^. 
4O3 as payload. UHTTP allows each data segn^ent 40„ 40^ 40, to be numbered. 

30 Referring to Figure 1 9. ESG data 32 is transmitted as a linked transfer and updated 
ESG. data 32'. is also transmitted as a linked transfer. For the ESG data 32, first, 
second and third UDP packets 41„ 41^, 41, are transmitted. Likewise, for tiie 
updated ESG 32', fourth, fifth and sixtii UDP packets 41„ 41,, 41« are transmitted. 
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In each case, if one or more UDP packet 41, 41„ 4I3. 4l„ 41,. 41, is unsuccessfuUy 
transmitted or data segment contained therein is unsuccessfuUy retrieved then 
corresponding UDP packets 41,. 41„ 4I3, .41., 41^, 4l, are re-transmitted' 

Descriptions of updated sessions are transmitted in a seventh UDP packet 41,. 

As described earUer. a default session announcement may be used to provide details 
of the full and updated session directories 29,:29,. An example of a default session 
announcement may include: 
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o=dcaster 4289098098 4289099125 IN IP4 130.230.3.2 
s=»Experiinental session directory service 

i=Full and update session directories delivered via UHTTP 
IS ushttp : //vrvw. datacas ter . com 
eadcas ter®datacas t er . com 
c=IN 1P4 224.2.17.12/127 
ts2873397496 2873404696 
xn=data 42451 udp uhttp 

asx-session-directory-full 
madata 42 452 udp ulifctp 

a«X-session-directory-updateB 
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In this example described, the fUll session amiouncements and updated session 
announcements are provided on different port numbers. Also in this example 
UHTTP is used full session amaouncements and updated session announcements 
However. UHTTP may be used for full session announcements, while SAP and SDP 
may still be used for updated session announcements. 

Numbering of data segments 40,. 40^. 4O3 allows the cUent 5 to detect when they 
have received the ESG data 32. Once this occurs, the cHent 5 listens for updates. 

The use of UHTTP has another advantage. It supports forward error correction 
(FEQ which can be used to increase the probabiUty of successful transmission even 
If bxt and burst errors occur in transmission. If. however, FEC fails to recover any 



errors at the client-end, the client 5 waits for periodic .UHTTP retransmission. 
Alternatively, if a return path is provided, then autpnaatic repeat request (ARQ) may 
• be used. . ! ' 

Other protocols which provide reliable deUvery of content may be used. 

Asynchronous Layer Coding (ALC), or a protocol based on ALC, provides reliable 
delivery of content and can be used to deliver full or partial ESG metadata, updates 
and notification of updates. 

Asynchronous Layer Coding (ALC) is a scalable reliable content delivery protocol 
for IP multicasting and reference is made to "Asynchronous Layer Coding protocol 
instantiation" by M. Luby, J. Gemmell, L. Vicisano, L. Rizzo and J. Crowcroft, RiFC 
3450, IETF, April 2002 and December 2002. 

Reference is also made to "ReUable Multicast Transport Building Blocks for One- 
to-Many Bulk-Data Transfer" by B. Whetten, L. Vicisano, R. Kermode, M. Handley, 
S. Floyd and M. Luby, RFC 3048, IETF, January 2001. 

Reference is also made to "Layered Coding Transport building block" by B. 
Whetten, L. Vicisano, L. Rizzo, M. Handley, S. Floyd and M. Luby, Internet Draft, 
IETF, February 2002. 

Session announcements, updates and notifications of updates 
using an JiiLC-based protocol 

ALC provides a unidirectional transport service for binary objects, such as files. 
ALC is based on the Layered Coding Transport (LCT) reliable multicast protocol 
building block and so inherits the LCT concept of sessions comprising one or more 
layered channels. 

An ALC/LCT session comprises of a set of logicaUy grouped channels associated, 
with a single sender carrying packets with ALC/LCT headers for one or more 
objects. For the deUvery of a fiiU or partial ESG, updates and notifications of the 
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updates, a protocol based on the ALC protocol may be used. Thus, an ESG session 
can be defined -vsrhich comprises one or more ]^SG channels. Each ESG channel 
corresponds to an ALC session. 

As explained- earlier, an ALC session comprises one or more ALC channels. Each 
ALC channel may be thought of as "bit pipe" for forwarding packets according to 
the ALC protocol. In preparation for an ALC session, a sender selects a number of 
ALC channels and chooses corresponding bitrates for each of them. Each recipient 
of the ALC session can control the receiving bitrate by selecting to receive either all 
ALC channels or only some of them. 

An ALC channel is uniquely definable and recognizable by a pair of variables (S, G). 
S is an IP unicast address of the sender and G is a multicast IP address for a 
multicast receiving group. G may also be a unicast IP address, but RFC 3450 does 
nbt define the use of unicast. 

An ALC session is uniquely definable and recognizable by a pair of variable (S, TSI). 
S is the unicast IP address of the sender and TSI is the value of the Transport 
Session Identifier field in the header of each ALC packet 47 (Figure 21). 

Using ALC or an ALC-based protocol, an ESG session may be defined which 
comprises at least one ESG channel. Preferably, the ESG session comprises, three 
ESG channels: one channel for deHvering a fuU or partial ESG, one channel for 
delivering updates and one channel to notify of updates. 

Each respective ESG channel carries data packets having the same value in the 
Transport Session Identifier (TSI) field. Data packets in the same channel are sent 
£tom the same source port and IP address, and may be addressed to a different 
destination port and/or IP address. 



In an embodiment of the present invention, an ESG session includes a full ESG 
channel, an ESG update channel and an ESG notify channel. 



The foil ESG channel repeatedly delivers an ESG metadata set representing the 
• sender's foil or partial ESG metadata set. When only a partial ESG is delivered^ 
clients may be provided access* to the foil ESG via a different protocol; such as a 
point-to-point ESG transpott protocol. . . « 

The update ESG channel repeatedly delivers an ESG metadata set cornprising parts 
o.f the sender's ESG that have changed since the current version of the full ESG 
was assembled. , 

The notify ESG channel repeatedly delivers a metadata set consisting of pointers to 
parts of the sender's ESG that have changed since the most recent version of the 
foil ESG was constructed. The pointers are data fields within the metadata set, 
which identify parts that have changed. 

Each of the ESG channels in turn may comprise one or more ALC channels. All 
ALC channels which constitute an ESG channel are sent on consecutive IP 
addresses. Only a base IP address used for each ESG channel needs to be signaUed 
to the receivers. This is because a "Next flag'' in a Congestion Control Indication 
field enables receivers to discover the foUowing IP addresses that may have been 
used for the current ESG channel. 

ESG receivers with interactive network connection are able to join, and leave 
transport channels, depending on the type of ESG metadata they need to receive 
and on the congestion status of the network, ESG receivers that only have 
unidirectional network connectivity are more restricted, but stiU have the option of 
filtering but unnecessary transport channels. Furthermore, a network element such 
as the ESG proxy (not shown) can reduce the number of transport channels 
forwarded to a unidirectional Unk, for example when congestion is detected at the 
feed of such a link. 

Referring to Figure 20, when sets of metadata 33/, 33^, 333, 33^, 335 (Figure 11) for 
an updated ESG 32* is prepared, a set of metadata 45 for notification of updates is 
also prepared. The metadata set 45 comprises pointers to any updated sessions 22,*, 
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225 (Figure 9). OptionaUy, metadata set 45 may be divided into a plurality of data 
segments -46^, 462. 

Referring Figure 21, a packet 47 for deUvering metadata sets or data segments is 
shown. Preferably, the packet 47 is substantially similar to a UDP or ALC packet 
and may comprise one or more headers, one or more payload data fields and other 
data fields. A standard header format, such as a UDP header, may be used. 

In this example, an ALC packet 47 is described which comprises a UDP header 48, 
an LCT header 49, an FEC payload ID field 50 and payload 51. which includes at 
least metadata sets 33, 45 or data segments 46i, 46^! 

Between them, the headers, preferably the LCT header 49, may comprise a number 
of fields (not shown) including a version number field and a number of flags (not 
shown) including a congestion control flag, a transport session identifier flag, a 
transport object identifier flag, a half-word flag, a sender current time present flag, 
an expected residual time present flag, a close session flag and a close object flag. 
Further data fields may be included which ate reserved for future use. 

The transport session identifier flag identifies the field format used for the transport 
session identifier. The transport object identifier flag indicates the field format used 
for transport object identifier. The sender current time present flag indicates the 
presence or absence of a sender current time field. The expected residual time 
present flag indicates the presence or absence of an expected residual time field. 
The close session flag indicates the ending of the session and the close object flag 
indicates the ending of the transmission of the object. 

Between them, the headers, preferably the LCT header 49. comprise a number of 
fields (not shown) indicating, the length of one or more of the headers and/or of the 
packet, a number of fields (not shown) with information relating to congestion 
control and one or more fields (not shown) including one or more identifiers for 
identifying the transport session and the transport object. 



Further data fields (not shown) may carry information, for example relating to ALC 
encoding symbols and to possible header extensions.. The further data fields (not 
shown) may include information on a Forward Error Correction (FEC) scheme 
used. FEC data is redundant information generated from, and interleaved with,. ' 
payload data. The use of FEC allows receivers to reconstruct payload data segments 
lost or damaged due to transmission errors. 

Between them, the headers, preferably the FEC payload ID field 50, includes a 
source block number (not shown) and an encoding symbol ID (not shown). 

The source block number indicates from which source block of the object the 
encoding symbol(s) in the payload 51 is (are) generated. The encoding symbol ID 
identifies which specific encoding symbol(s) generated from the source block is 
(are) are carried in the payload 51. 

When a protocol based on the ALC is used, an ALC Protocol Instantiation specific 
header extension (not shown) is included at least once in the delivery of each 
transport object. An FEC Object Transmission Information in the header 
extension enables receivers to discover, in-band, the FEC parameters used to deUver 
the associated transport object. 

A header extension (not shown) comprises one or more fields such as a type of the 
header extension, a length of the. header extension, an identification for the FEC 
encoder being used, a transfer length of the object, a source block length of every 
source block of the current transport object carried in the packet payloads. a length 
of every encoding symbol of the current transport object carried in packet payloads. 
In addition the header extension may comprise one or more fields reserved for 
future use. 



The information in the congestion control field may comprise an indication flag, a 
sequence number the value of which is increased by one for each packet sent, 
wherein it can be used by receivers to detect packet loss and a part reserved for 
future use. 
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When the indication flag is set to 'V, it indicates that the current ALC session 
consists of two or mote ALC channels including the current IP address and the next 
consecutive IP. address. A value of '0' in this field indicates that the cuirrent IP 
address is the highest IP address in the current ALC session. Receivers may 
monitor this field to detect dynamic addition or deletion of ALC channels by ESG 
senders. 

Further details relating to ALC packet formatcan be found in "Asynchronous Layer 
Coding protocol instantiation", RFC 3450, ibid. 



In an embodiment of the present invention, die announcements can be regarded as 
binary objects and dius be called transport objects. Each transport object is 
identified by tiie value of a transport object identifier field (not shown), which is 
15 unique within the scope of one transport session. Each ESG metadata set is 
preferably sent as a separate transport object. 

For each transport object, additional information may be defined in die form of an 
ESG deHvery table (not shown). On tiie sender side, ESG deUvery table can be 
insetted in every transport session. On tiie receiver-side, ESG deUvery table 
information parsing can be provided. 

For each type of transport channel in a transport session, a different delivery table 
can be transmitted. ' 

The ESG deHvery table (not shown) may be defined as a set of mappings, each 
comprising a transport object identifier value and the properties of die transport 
object. The ESG deUvery table may comprise two parts: an ESG header and an 
ESG payload. 

The ESG deHvery table header comprises fields for header extension type, header 
extension lengtii, ESG deHvery table version and ESG deUvery table expiry. 



The! ESG header extension is a variable length piotocol instantiation specific' header 
extension and it is included in all packets carrying ESG delivery table and it is 
identical for all packets carrying the same version of the ESG delivery fable. The 
ESG delivery table version is the nvunber of the currently transmitted ESG delivery 
table. This field has the value of '0' for the ESG delivery table of a new ALC 
transport session, and is increased by one whenever an updated ESG deliyety table 
is constructed for the same ALC ttansport session. After reaching its predefined 
maximum value, the version number wraps back to '0'. The ESG delivery table 
expiry is a time value, indicating the time after which the ESG delivery table is not 
expected to be valid. A new version of the ESG delivery table is preferably sent 
before the expiry time of the current version. However, receivers should continue 
using the current version of the ESG deUvery tabfe even after its expiry time if they 
have not received a newer version. 

The ESG payload contains the actual mappings between transport object identifiers 
and the attributes associated with the transport object identified by each transport 
object identifier. The ESG payload format may be an XML structure represented as 
ASCII text, comprising one or more fields such as e.g. a unique identifier for the 
transport object within the current ALC transport session, a URL for uniquely 
identifying the current transport object, the length in bytes of the transport object, 
the MIME type of the transport object, an identifier for the encoding used for the 
transport object, such as ZLIB compression and an MD5 cfaecksiim for the 
transport object. The ESG payload fields may use the syntax and semantics of the 
corresponding fields defined in the HTTP 1.1 specification. 

Referring to Figure 23. dehvery of a full ESG as a first set of announcements 37,. 
deUvery of updated ESG as a second set of announcements 372 and deUvery of 
notifications of the updates as a third set of announcements 373 are shown. 

As explained earlier, announcements comprising notification of updates can be sent 
more frequently than announcements comprising updates. 
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The datacast cUent 5 can choose to listen to" announcements comprising 
notifications of updates in preference to announcements comprising updates If 
they receive a notification of an update to a session in which the user may be 
interested,, then the datacast dient 5 can Usten to announcements comprising 
r updates and/or obtain a description of the session in another way, such by unicast. 

Time Division Multiplexing 

In the embodiments described earher, IP packers comprising portions of ESG data 
32, 32' can be transmitted by the datacaster 3 to the cUent 5 as-and-when 
transmission slots become available. However, to ensure that the chent 5 receives 
the IP packets, it is preferable that the client 5 be configured to receive data at any 
tmie. This has the drawback of unnecessarily using processing and electrical power. 

A solution to this problem is to employ time division multiplexing CTDM).. 

Referring to Figure 23, an alternative manner of transmitting a description of the 
session directory 28 is shown. In this example, only a later cycle 38,' including the 
two types of session announcements 37„ 37, is shown. 

Announcements of the first type 37. for describing ESG data and announcements 
of the second type 37, for describing updates to ESG data are transmitted in 
different time slots 52„ 52, For example, the announcements of the first and 
second types 37.. 37, are transmitted in alternate time slots. However, the time 
slots 52„ 52, need not be adjacent. The time slots may be of variable or fixed 
length. 

Thus, if the chent 5 wishes to listen for updates to ESG data, then they do not need 
to hsten to time slots 52, during which announcements of the first type 37. are 
transmitted, but may listen to time slots 52, during which only announcemlnts of 
ti.e second type 37, are sent. This allows the client 5 to switch off its receiver 14 
(Figure 1) during time slots 52,. The ESG data contains information when the 
receiver of the client needs to be turned on or off and/or when tiie content is on " 
tiie air witiiin service area defined by datacast operator • 



Datacast client 5 . . 

Referring to Figvire 24, the datacast client 5 comprises a processor 53, input/ output 
interface 54, memory 55, a receiver 56 and a transceiver 57 which are connected via 
a bus 58. The input/output interface 54 is connected to a user interface 59, a 
display 60, storage 61 and speaker 62. 

The datacast client 5 may be a handheld mobile communication device for use with 
first and second wireless conmiimicatibn networks in accordance with the present 
invention. For example, the first wireless communication network may be a DVB-T 
or DAB network, or any modification of these or similar networks, and the receiver 
56 may be configured to receive and demodulate signals frbm such a network. The. 
second wireless communication network may be a UMTS networj^ ot other 3G, 
2.5G or 2G telecommimications network and the transceiver 57 may be configured 
to receive/ transmit and demodulate /modulate signals via a UMTS or similar 
network. 

The datacast client 5 may be a set-top box connected to a television set for use with 
first and second wired and/or wireless communication networks. For example, the 
first communication network may be a DVB-T network and the receiver 56 may be 
configured to receive and demodulate signals from a DVB-T network. The second 
conamunications network may the Internet and the transceiver 57 may include a 
modem (not shown) for connection via a public switched telephone network to an 
Internet Service Provider . 

Using two networks, sessions and session announcements may be transmitted over 
different networks. Alternatively, the first and second types of session 
announcements may be transmitted over different networks. 

When two networks are available, the user of the client device may control the 
delivery of full or partial ESQ metadata, updates thereof and notifications of 
updates by using a request-response model, wherein the requests are transmitted to 
the datacast service system through the second communications network. In the 
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communication between the cUent and the datacast service acknowledgements may 
be used if lequired. The client may make a request for notifications using the 
second communications network, wherein selected notifications are transmitted to 
the client when such notifications are created. 

I 

Computer programs (not shown) when loaded into memory 55 and run by the 
processor 53 cause the processor 53, in conjunction with other elements of .the 
device, to provide the service discovery cUent 15, the ESG browser 17,. the content 
filtering application 18 and the content browser 20 respectively. Storage 61 is used 
to hold the ESG and content databases 16, 19. The user interface 59 allows the 
user to provide instructions to the ESG browser 17.and the content browser 20. 
such as instruction to select a session. The display 60 aUows the user to view 
session descriptions and session content. The speaker 62 allows the user to hear 
session content. . 

ESG browser 

Referring to Figure 25, an example of an ESG browser window 63 is shown. The 
window 63 includes a first section 64 for receiving instructions for filtering sessions, 
for example on the basis of date of transmission, whether a session is current being 
transmitted or search terms. The window 63 includes a second section 65 for 
displayiiig a Hst of filtered sessions and receiving instructions to select a session. 
The window 63 includes a third section 66 for displaying a description of a selected 
session and receiving instructions to access the session. 

It wiU be appreciated that many modifications may be made to die embodiment 
hereinbefore described. 

Session announcements may be unicast, rather than multicast, to a dient. 

Sessions and session announcements may be transmitted over different networks. 
For example, sessions may be transmitted over a DVB network and session 
announcements may be sent via a DAB network. 



The first and second types of session announcements may be transmitted over 
different networks. For instance, announcements of the first type may be 
transmitted dirough a DVB-T network, while announcements of the sdcond type 
may be sent though a 3G network. The first and second, types of session 
announcements may be transmitted through the same network, but over one or 
more different physical channels, for example at different carrier frequencies. The 
first and second types of session announcements may be transmitted through the 
same network and over the same physical channels, but over one or more different 
logical channels. 

From reading the present disclosure, other variations and modifications wiU be 
apparent to persons skiUed in the art. Such variations and modifications may 
mvolve equivalent and other features which are akeady made in design, manufacture 
and use of systems for announcing sessions an'd component parts thereof and which 
may be used instead of or in addition to features akeady described herein. 

Although claims have been formulated in this appHcation to particular combinations 
of features, it should be understood that the scope of disclosure of the present 
invention also includes any number of features or any other combinations of 
features disclosed herein either impUcidy or explicitiy or any generaUsation diereof, 
whetiier or not it relates to tiie same invention as presentiy claimed in any claim or 
whether or not it mitigates any or all of the scientific problems as does the present 
invention. The appUcants hereby give notice that new claims may be formulated to 
such features and/or combination of features during the prosecution of tixe present 
application or any fiirther appHcation derived therefcom. 
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Claims 

1- A jtiiethod .of announcing sessions transmitted' through a network, the method 
comprising: 

providing a first set of aimouncements describing a plxirality of sessions; and 
providing a second set of announcements describing at least one updated 
session. 

2. A method according to claim 1, comprising providing said first set of 
announcements through a first channel and providing said second set of 
axmouncements through a second, different channel. 

3. A method according to claim 1 or 2, wherein providing said first set of 
announcements and providing said second set of annoimcements comprises 
providing said first set of announcements through a first address and providing said 
second set of announcements through a second, different address respectively. 

4. A method according to any preceding claim, wherein providing said first set of 
announcements and providing said second set of announcements comprises 
providing said first set of announcements through a first destination address and ; 
providing said second set of announcements through a second, different destination 
address respectively. ' 

5. A method according to any preceding claim, wherein providing said first set of 
announcements and providing said second set of announcements comprises 
providing said first set of announcements through a first IP address and providing 
said second set of announcements through a second, different IP address 
respectively. 

6. A method according to any preceding claim, wherein providing said first set of 
announcements and providing said second set of announcements comprises 
providing said first set of announcements through a first IP multicast address and 



providing said second set of announcements through a second, different IP ' 

I . . ' 

multicast address respectively, 

t 

7. A method according to any preceding claim, wherein providing said fhrst set of 
announcements and providing said second set of announcements comprises 
providmg said first set of announcements through a first port number and providing 
said second set of announcements through a second, different port number 
respectively. 

8. A method according to any preceding claim, wherein providing said first set of 
announcements and providing said second set of announcements comprises 
providing said first set of announcements through a first logical channel and 
providing said second set of announcements through a second, different logical 
channel respectively. 

9. A method according any preceding daim, wherein providing said first set of 
announcements and providing said second set of announcements comprises 
including in each announcement of said first set of announcements data for 
identifying said announcement as an announcement which describes a one of said 
plurality of sessions and in each announcement of said second set of 
announcements data for identifying said announcement as an announcement which 
describes a one of said at least one updated session. 

10. A method according any preceding claim, wherein providing said first set of 
announcements and providing said second set of announcements comprises 
including in each announcement of said first set of announcements respective data 
for specifying a position of a corresponding session within a first portion of a 
session directory and including in each announcement of said second set of 
announcements respective data for specifying a position of a corresponding session 
within a second portion' of the session directory. 

11. A method according to any preceding claim, wherein providing said first set of 
announcements and.providing said second set of announcements comprises 
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providing said to. ,et of anno„nc«.enb tfupugh , first phyaicl chaond .„d 
provd^g. said second s« of .nnouncen>en« through a second, different physical 

Channel respectively. • . 

< 12. A method according to ,n, preceding cUin,.wherdn providing said first set of 
announcements and proWding said second set of an.o«.cemen.s comprises 
provdmg said first s« of announcements through a first network and providing 
sard second set of .«„uncem«,t, through . s^ond. different network respectively. 

U. A method according to any preceding clairu. further comprising providing a 
thrrd set of announcements deacribing another plurality of sessions including said at 

least one updated session. 6 

r . ' ' 

14. A method according to any preceding claim, comprising: 

providing said first set of amiouncements through a first chamiel- 
providing said second set of announcements describing at least ole updated 

session through a second, different channel; and 

providing a third set of amiouncements describing anotiier pluraUty of 

sessions including said at least one updated session through said first channel. 

15. A method according to any preceding claim, comprising arranging the 
prov^dmg of said second set of amiouncements after the providing of said first set 
or announcements. 

16. A method according to any preceding claim, wherein providing said first set of 
am.ounc.„ents and providing said second se, of announcements comprises 
ttansmttting aaid first set of «mouncemen.s through a first channel and 
transmitting said second set of amiouncements through a second, different channcL 

17. A method according to any preceding claim, comprising transmitting said first 
set of announcements according to a session aonomrcem«>t protocol (SAP). 



18. A method according to any preceding claim, comprising transmitting said first 

set of announcements according to a xmidirectional transport protocol. 

'i* . 
I 

19. A method according to any preceding claim, comprising transmitting said first 
set of announcements according to unidirectional hypertext transfer protocol 
(UHTTP). 

20. A method according to any preceding claim, comprising transmitting said first 
set of announcements according to asynchronous layered coding (ALC) protocoL 

21 . A method according to any preceding claim, comprising transmitting said first 
set of announcements according to user datagram protocol (UDP). 

22. A method according to any preceding claim, comprising including a 
description of a corresponding session in each announcement. 

23. A method according to any preceding claim, comprising including a 
description of a corresponding session arranged according to session description 
protocol (SDP) in each announcement. 

24. A method according to any preceding claim, comprising providing means for 
determining whether all of said first set of announcements have been provided. 

25. A method according to any preceding claim, comprising providing said first 
set of announcements as a series of linked messages. 

26. A method according to any preceding claim, comprising providing said first 
set of announcements in a first set of time slots and providing said second set of 
announcements in a second set of time slots, each timeslot of said first set of 
timeslots being provided at a different time firom each timeslot of said second set of 
time'slots. 
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27. A method according to any preceding claim, comprising multiplexing said first 
and second sets of annoimcements. 

28. A method, according to any preceding claim, further comprising providing a 
third set of annoimcements identifying said at least one updated session. 

29. A method according to any preceding claim, wherein providing the segond set 
of announcements describing the at least one updated session comprisejs providing a 
set of announcements identifying the at least one updated session. 

30. A method according to any preceding claim, wherein providing the second set 
of announcements describing the at least one updated session further comprises 
including a description of a corresponding session. 

31. A method according to any preceding claim, wherein providing the second set 
of announcements describing the at least one updated session comprises providing a 
set of notifications pointing to the at least one updated session. 

32. A method of announcing sessions transmitted through a network, the method 
comprising: 

providing a first set of announcements describing a' plurality of sessions; and 
providing a second set of aimouncements identifying at least one updated 
session. 

33. A method according to claim 32, further providing a third set of 
announcements describing said at least one updated session. 

34. A method according to any preceding claim, comprising transmitting at least, 
one of said sets of announcements according to asynchronous layered coding (ALC) 
protocol. 



35. A method accotding to any preceding claim, coniprising transmitting at least 
one of said sets of announcements according to a protocol based on asynchronous 
layered coding (ALC) protocol. , * . « 

I 

36. A method according to any preceding claim, comprising defining an 
asynchronous layered coding (ALC) protocol session and defining at least one ALC 
channel. 

37. A method according to claim 36, comprising transmitting a set of metadata for 
describing the plurality of sessions via a first ALC channel. 

38. A method according to claim 36 or 37, comprising transmitting a set of 
metadata for describing at least one updated session via a second, different ALC 
channel. 

39. A method according to claim 36, 37 or 38, comprising transmitting a set of 
metadata for identifying said at least one updated session via a third, different ALC 
channel. 

40. A method according to any one of claims 33 to 39, comprising transmitting a 
one set of metadata as a transport object. 

41. A method according to claim 40, further comprising defining a respective 
dehvery table relating to the transport object and transmitting said .deUvery table. 

42. A method substantiaUy as hereinbefore described with reference to Figures 1 , 
9 to 15 of the accompanying drawings. 



43. A method substantially as hereinbefore described with reference to Figures 1 , 
10 to 16 of the accompanying drawings. 



44. A 



computet program which, when .execu.ted by data processing apparatus, 
causes the data processing apparatus to perform a method of announcing 
ttansmitted through a network according to any preceding claim. 



sessions 



45. A method of accessing sessions transmitted through a network, the method 

comprising: 

selectively receiving a first set of announcements describing a plurality of 
sessions; and 

selectively receiving a second set of announcements describing at least one 
Updated session. 

46. A method according to 45. further comprising determining whether all of said 
first set of announcements have been receiyed. 

47. A method according to claim 46, further comprising selecting not to receive 
further said first set of announcements and selecting to receive said second set of 

' announcements. 

48. A method according to claim 45 or 46. further comprising selecting not to 
receive a third set of announcements describing another plurahty of sessions 
including said at least one updated session. 

49. A method according to any one of claims 45 to 49. further comprising 
selecting to receive a fourth set of announcements describing at least one fixrther 
Updated session. 

50. A method according to any one of claims 45 to 49, comprising using said 
second set of announcements to identify said at least one updated session. 

51. A method according to claim 50. comprising selecting to receive another set of 
announcements.including a description of said at least one updated session. 



52. A method according to claim 50, comprising obtaining a description of said ai 
least one updated session. 

53. A method of accessing* sessions transmitted through a network, the method 
comprising: 

selectively receiving a first set of announcements describing a plurality of 
sessions; and 

selectively receiving a second set of announcements identifying at least one 
updated session. 

54. A method according to claim 53 further comprising 

selectively receiving a third set of announcements describing said at least one 
updated session. 

55. A method of accessing sessions transmitted through a network, the method 
comprising: 

listening to a first set of announcements describing a plurality of sessions; 
determining whether said first set of announcements have been received; 
if said first set of announcements have been received, then 
stopping listening to said first set of announcements and 
listening to a second set of announcements describing at least one updated 
session. 

56. A method according to claim 55, further comprising: 

stopping listening to a third set of announcements describing a further 
plurality of sessions including said at least one updated session. 

57. Apparatus for announcing sessions transmitted through a network, the 
apparatus comprising: 

means for providing a first set of announcements describing a plurality of 
sessions; and 

means for providing a second set of announcements describing at least one 
updated session. 
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58. Apparatus for pexfoiming the method according to any one of claims 1 to 43. 

59. Apparatus for announcing sessions transmitted through a network 
substantiaUy as hereinbefore described with reference to Figures 1 , 9 to 15 of the 
accompanying drawings. 

60. Apparatus for announcing sessions ttansnaitted through a network 
substantially as hereinbefore described with reference to Figures 1 , 10 to 16 of the 
accompanying drawings. 

61. Apparatus for announcing sessions transmitted through a network, the 
apparatus comprising: 

a first transmitter for providing a first set of announcements describing a 
plurality of sessions; and 

a second transmitter for. providing a second set of announcements describing 
. at least one updated session. 

62. Apparatus for accessing sessions transmitted through a network, the apparatus 
comprising: 

means for selectively receiving a first set of atmouncements describing a 
plurality of sessions; and 

means for selectively receiving a second set of announcements describing at 
least one updated session. 

63. Apparatus according to claim 62, comprising: 

means for determining whether said first set of announcements has been 
received; 

said apparatus being configured such that if said determining means 
determines that said first set of announcements has been received, then the means 
for selectively receiving said second set of announcements is configured to receive 
said second set of annoxmcements. 



64. Apparatus according to claim 63, comprising: . , • ' 
means for selectively teceiying a third set of aimouncements describing 

another plurality of session including said at least one updated session;'' 

said apparatus being configured such that if said determining means 
determines that said first set of announcements has been received, then the means 
for selectively receiving said third set of announcements is configured not to receive 
or not to forward said third set of announcements. 

65. Apparatus according to any one of claims 62 to 64 which is a mobile 
communications device. • 

66. Apparatus for accessing sessions transmitted through a network substantially 
as hereinbefore described with reference to Figures 1 to 22 of the accompanying 
drawings. 

67. A system for presenting program schedule data on a display, said system 
comprising at least two announcements, the schedule data being organized at least 
partly from a first set of announcements describing at least partly a pluraUty of 
sessions and at least partly from a second set of announcements describing at least 
one at least partly updated session. 

68. A system for presenting program schedule data on a display, said system 
comprising at least two announcements, the schedule data being organized at least 
partly from a first set of repeatable announcements describing a plurality of 
sessions, at least partly from a second set of repeatable announcements describing at 
least one at least partly updated session and at least session descriptions of at least 
one of the repeatable announcements for defining whether the at least one of the 
first and second announcements is received or not. 

69. A system for delivering program schedule data to end-user terminals, said 
system comprising two sets of announcements, each set comprising at least one 
announcement, the schedule data being organized at least pardy from a first set of 
announcements describing at least partly a pluraUty of sessions and at least partly 



firoin a second set of announcements describing at least one at least partly updated 
session. • . 



70. A system for presenting program schedule data to end-user terminals^ said 
system comprising at least two set of announcements, each set comprising at least 
one announcement, the schedule data being organized at least partly from a first set 
of repeatable announcements describing a plurality of sessions, at least partly from a 
second set of repeatable announcements describing at least one at least; partly 
updated session and at least session descriptibns of at least one of the repeatable 
announcements for defining whether the at least one of the first and second 
announcements is received or not- 

71. A system according to any one of claims 68 to 70 claim, wherein the second 
set of announcements include a version number of each updated session for 
allowing a client to detect if they have missed an earlier update. 

72. A system accordiag to claim 71, wherein if a client detects it has missed an 
earlier update and is not currently receiving the first set of announcements, the 
client starts receiving the first set of announcements until it has received a fiiU and- 
latest version of the program schedule data. 

73. A system according to claim 72, wherein if the client detects that it has 
received a full and latest version of the program schedule data, it stops receiving the 
first set of announcements and continues receiving only the second set of 
announcements. 

74. A system according to any one of claims 71 to 73, wherein if the client detects 
it has missed an earUer update, it fetches a fiiU and latest version of the program 
schedule data over an interactive network. 

75. A system according to any one of claim 78 to 74, where each set of repeatable 
announcements is divided into segments before transmission and a location of each 
segment within a whole transfer is indicated in a framing field of each respective 



segment; the indicated location enables clients to determine whether they have 
received all segments that constitute a given set or whether they need to wait for 

receiving more segments. . ? * 

I * 

76. A system accotding to any one of claims 78 to 75, wherein the ptogram 
schedule data is viewed either direcdy by a human end-user or autotriaticaUy used by 
a software application. 

77. A system according to any one of claims 78 to 76, wherein the program 
schedule data is presented progressively to a human end-user or made progressively 
available to an automatic software application as the said data is being receiyed. 

78. A system according to claim 76 or. 77, wherein the program schedule data is 
viewed by a human end-user via a graphical user interface. 



79. A system according to claim 76 or 77, wherein the program schedule data is 
used by a personal video recorder. 



) 
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Abstract 

A method of announcing sessions 

An electipnic service guide (ESG) is provided by transmitting announcements 
describing nxultiniedia sessions, sucli video streams. Sessions are organised into a 
session directory (28) which is spUt into two parts: a fiill session directory (29,) and 
an updated session directory (29^. A first kind of announcement describes aU 
sessions in the fuU session directory. A second kind of announcement describes 
sessions in the updated session directory. Once a client has received a description 
of the fiill session directory, it need only Usten to announcements of the second 
type so as to learn of any updates to sessions. 



(Figure 8) 
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